home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
tag_bbs
/
tag_sh32.zip
/
TAG_SHUT.DOC
< prev
next >
Wrap
Text File
|
1992-04-13
|
19KB
|
461 lines
Are you tired of those annoying one time callers who log on to your BBS
only once, and never return again, leaving you with a wasted user record?
Are you a sysop who is looking for a way to screen users before allowing
them to have an account on your bbs?
Are you looking for an extra little edge against the Big Hack-Attack that
worries so many sysops running "open" TAG systems?
Are you a sysop who caters to the non-public domain LEECH and need a way
to add more pinache to your system (recent upload bulletins etc.) that the
general public can't see?
WELL THEN READ ON, BECAUSE.......
TTTTTTTT AAAAAAA GGGGGGG SSSSSSSS HH HH UU UU TTTTTTTT
TT AA AA GG GG SS SS HH HH UU UU TT
TT AA AA GG SS HH HH UU UU TT
TT AAAAAAA GG GGG SSSSSSSS HHHHHHH UU UU TT
TT AA AA GG GG SS HH HH UU UU TT
TT AA AA GG GG SS SS HH HH UU UU TT
TT AA AA GGGGGGG ========= SSSSSSSS HH HH UUUUUUUU TT
*_THE_* Shuttle Log-on door for T.A.G.
has arrived
TAG_SHUT
------------
A Shuttle Log-On Door for TAG BBS's
A brief comment from the author (me):
I wrote this door to fill a gap for converted Telegard SysOps (yup, I was one
of them once too!). There seemed to be a lot of sysops around who had convert-
ed from Telegard to TAG and one of the features they found to be lacking was
a so-called "Shuttle" menu. Personally, I found them to be quite annoying,
but, since there was a need, I took it upon myself to fill the gap.
You know what? Since I have been running it, I have come to like it!! It does
a great job of looking after all of those annoying call one time type of bbs
users who just love to eat up user list space.
I may or may not continue to work on this door, depending on the reception it
gets in the TAG community. The program is provided as-is, without charge for
those who choose to run it. Registration in most cases, is *_NOT_* required.
But it is an option that is available to those who wish to do so. The door will
function just fine as-is. BUT, ! Registration does have it's advantages!
PLEASE READ THE ENCLOSED TAG_SHUT.REG FILE !!
The person who sends me the *_BEST_* questionnaire file, that best shows off
the abilities (such as they are) of the questionnaire system, will have their
questionnaire file included in the distribution files and honourable mention of
their efforts given in the credits section of the docs. Not too mention, that I
will be forever grateful and willing to allow said person to test any upcoming
releases (boy, now there's a bonus!).
The docs for the program are broken down into the following areas:
2) Start up
3) SHUTTLE.CFG file, options
4) Questionnaire file, options
5) Undocumented features.
6) Credit where credit is due.
Special note : R.T.F.D. (Read The Faruking Docs!!)
Translation : Read, what you are doing now
Faruk, being the handle I use on my bbs
Docs, the file that quite often accompanies a program and tries
to explain the operation and set-up of the program which so many
sysops tend to try and avoid reading.
*-----------------------------------------------------------------*
Start-up :
1) Put the files, Shuttle.EXE, Shuttle.CFG, Newuser.APP (if used) and
MakeMsg.EXE in some directory you wish to run TAG_SHUT from. On my system
I have a directory off of my base BBS directory called shuttle and it runs
from there.
2) Create a (or edit the enclosed) file called WELCOME.BAT in your main bbs
directory. This file needs to copy the file DORINFO1.DEF into the dir that
SHUTTLE.EXE is located in, switch to that directory and run SHUTTLE.EXE
Example: (for a standard TAG 2.6 system)
@ECHO OFF
COPY DORINFO1.DEF SHUTTLE (puts dorinfo1.def in shuttle dir)
CD SHUTTLE (go to shuttle dir)
SHUTTLE (runs shuttle)
DEL DORINFO1.DEF (deletes dorinfo1.def after use (yes, it should!))
CD .. (changes back to the main BBS dir)
EXIT (back to the bbs)
Example: (for a TAG 2.6a+ beta system or the upcoming multi-user system)
@ECHO OFF
COPY DORINFO#.DEF SHUTTLE\DORINFO1.DEF (puts dorinfo1.def in shuttle dir)
CD SHUTTLE (go to shuttle dir)
SHUTTLE (runs shuttle)
DEL DORINFO1.DEF (deletes dorinfo1.def after use (yes, it should!))
CD .. (changes back to the main BBS dir)
EXIT (back to the bbs)
Note: DORINFO#.DEF is created for 2.6a single-user system such as mine. TAG
should create DORINFO#.DEF according to your system if running multiple
nodes, and WELCOME.BAT should be edited accordingly. At the moment, my
door ONLY supports dorinfo1.def, and may change soon if a need is seen.
*-----------------------------------------------------------------*
SETTING UP THE SHUTTLE.CFG FILE
Shuttle.cfg file contents:
enter_system <------ Password to enter system
yes <------ option to force shuttle locally
yes <------ was for, uhm, uhh, oh ya!
15 <------ Maximum time in door
5 <------ Maximum inactivity time (kills sleepers!)
c:\bbs\dfiles <------ Path to your USER.LST (NO TRAILING SLASH!!)
Faruk You <------ Who to send request for access msg to
c:\bbs\email <------ Where to put request for access msg.
New User Application <------ Title of request for access msg.
new_user_read_mail <------ Password to read reply msg. from sysop
or whomever msg. request for access message
was sent to.
Password to enter system:
No other checking is done on a user for validity. It
is not necessary for a user to have a valid account, as TAG will trap the user
with it's new user log-on.
Option to force local:
Simple YES or no here will dictate whether or not the
shuttle will check a user for local log on. I may do some work on this in the
near future and fix a couple small holes in the local log on. As it is now, all
you need do is either enter the password or hit (G) to hang up and you are in
the bbs. (Actually you are already, and TAG has no way to know whether or not
you should be. I may reboot the entire system at this point eventually).
Uhm, er, uhh :
Will be an option to specify whether or not a user may (F)ind
out the system password. (Yet more security? sheesh....)
Max time in door:
T.A.G. 2.6 (standard, upgrade, whatever) writes DORINFO1.DEF
with a max time of 500 minutes in the door. Definitely not desirable!
Max idle time:
Specifies max time a user may sit and stare at a prompt without
showing some sort of life form.
Path to USER.LST:
Gee. Wonder what that would be? (must be fully qualified
path to TAG's USER.LST file less trailing backslash.
User name to post "Request for access" msg to:
This is the name of the user to
post the new user to (contents of questionnaire). May be SysOp (TAG knows who
you are), or your handle/name or anyone else (valid of course) on the system.
Path to post message:
This should be the path to your Area 0 private EMAIL
directory. Can be any fido compatible *.MSG directory, (NET or ECHO also) but
EMAIL is best.
Title to place on new user message:
Pretty much self explanatory. All new user
requests will have this title on them.
New user read mail password:
This is the password the new user MUST enter in
order to be able to read the reply left to them regarding their request for
access. ONLY NON-USERS have access to this command to prevent theft of mail
that belongs to valid system members. THIS WILL NEVER CHANGE, SO DON'T ASK!!
There really is no special info needed for the format of the .cfg file. Just
take and edit the enclosed file to suit your needs and you are all set here.
*-----------------------------------------------------------------*
SETTING UP THE NEWUSER.APP FILE
Example file:
#What's your real name ? @Q@
#What's your reason for wishing access to this bbs? >@Q@
cmd color 0 6 0
#Are you a sysop of a bbs? @O@
#Is your hair brown? @O@
cmd color 0 3 0
cmd cls
... display a screen of system info ...
.
.
This is the end of the displayed page, press any key to go on@P@
cmd color 0 4 0
Thanks for your time. Please call back in a day or two to check
and see if you have a reply to your application.
*------------------------------------------------------------------*
Valid commands for use in the newuser.app questionnaire file
@Q@
@O@
@$@
>
#
@P@
cmd cls
cmd color 0 5 0
Explanation of commands:
@Q@ - specifies a MANADATORY question. User must supply at least 1 character
of input to answer and go on. (don't ask!)
@O@ - specifies an OPTIONAL question to ask of the user. Just hitting C/R will
go on past the question and output a blank line to the answer message.
@$@ - specifies input of a phone number from the user (North American format).
> - placed in front of either of the @Q@ or @O@ prompts will force a line-
feed and carriage return before prompting for an answer to the output
line.
# - Forces line to be included in the answer message.
@P@ - force a pause at current line. Produces a [Paused] prompt.
cmd cls - clears both local and remote screens when processed.
cmd color - changes colors.
command syntax : cmd color x y z
x being background color
y being foreground color
z being blinking if 1 and no blink if 0
Valid Background Colours :
0 : black 4 : red
1 : blue 5 : magenta
2 : green 6 : brown
3 : cyan 7 : light gray
Valid Foreground Colours :
0 : black 4 : red 8 : dark gray 12 : light red
1 : blue 5 : magenta 9 : light blue 13 : light magenta
2 : green 6 : brown 10 : light green 14 : yellow
3 : cyan 7 : light gray 11 : light cyan 15 : white
See that blank line right up here ^^^^^^^^^^^^^ ?
Yup, you guessed it, a blank line is just that, a blank line and is displayed
that way. Text lines may also be added wherever you so choose.
*----------------------------------------------------------------- *
Other important stuff:
1) The F10 key will initiate a chat mode at ANY time. Split screen
mode or single line (you type first, user types next) will be
chosen depending on whether or not the user has ansi.
2) The F1 key when pressed in chat will drop the user back to the
point at which they left off.
3) The F9 key when pressed, hits the user with fake line noise.
4) The F8 key when pressed, hits the user with fake line noise and
then disconnects the call.
5) The chat page is enabled/disabled via the scroll lock key.
Scroll on / chat page bell on. Scroll off / chat page bell off.
6) The screen is restored in mono after a sysop initiated chat,
sorry, but at the moment it's the best I can do (which by the
way is a far cry better than most chat utilities do).
7) If found, either MENU.CLR or MENU.MSG will be displayed in place
of the built in main menu. File(s) must be in same directory that
SHUTTLE.EXE was run from
8) If found, either WELCOME.CLR or WELCOME.MSG will be displayed in
place of the built in welcome message. File(s) must be in same
directory that SHUTTLE.EXE was run from.
HINT: remove welcome.msg and clr from TAG's directory (A or G FILES)
and replace them with an empty file of the same name. This will
allow TAG to detect ansi and funtion without errors while not
forcing users to spend all of their online time looking at ANSI
screens. Makes for a nice seamless interface.
9) This program is 99.99% safe for use in a multi-user system. It
only reads from the user.lst file and TAG "may" try and write
to it while TAG_SHUT has it open. TAG_SHUT only keeps the file
open for a very brief time in read-only mode, so that should
not be a problem under most circumstances. If anyone finds that
their user.lst file gets blown away while using this door in
a multi-user system, PLEASE NOTIFY ME !!
10) Questionnaire lines are limited and truncated to 78 characters.
*----------------------------------------------------------------- *
UNDOCUMENTED FEATURES
In keeping with the true tradition of TAG, bugs are non existant unless they
are proven to be FTSC compatible ANNOYING and/or OFFENSIVE. Otherwise, they
are to be considered only as undocumented features, all of which I would very
much like to hear of so that I may include them in the docs. :-)
Further to this portion of the documentation, all undocumented features will
see inclusion to the system/docs in approximately a WWeek, which for those who
may be as yet uninitiated, is roughly three weeks from the Tuesday after my
Mothers 92nd birthday (anytime sooner is a bonus for you!).
*----------------------------------------------------------------- *
Credit where due:
First of all, I must give credit to my girlfriend Brita without who's
patience and understanding this door would not exist, much less that my
BBS and TAG Alpha support for Canada would likely not exist either.
Thanks Sweetheart, and please continue to be as patient as you have.
Secondly, my children, Teddy and Hillary. You guys have sacrificed a lot of
my time in order that I can develop this package and I promise that come
summer, we'll see lots of the good times again.
I love you two guys!
NEXTLY:
THE
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/\/\/\/ \/\/\/\
| /\/ ______________ ______ ___________ \/\ |
| / / / /| / /| / /\ \ \ |
| / / TTTTTTTTTTTTTT/ AAAAAA /| GGGGGGGGGGG\/| \ \ |
|/\/ /\ TT | AA|___AA /| GG | GG/ /\ \/\|
|-< < > TT | AA/ AA /| GG | _____ < > >-|
|\/\ \/ TT | AAAAAAAAAAAA | GG | / /| \/ /\/|
| \ \ TT | AA | AA | GG |__GGGGGG | / / |
| \ \ TT | AA | AA | GG/ GG | / / |
| \/\ TT/ <> AA/ AA/ <> GGGGGGGGGGG/ <> /\/ |
\/\/\/\ /\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
TEAM
Thanks guys, (Vic, Randy and Paul especially), if it were not for you guys
and your generosity none of us would have this fine BBS package to run.
And finally:
Rod Bowman
and
┌──────────────────────────────────────────────┐
│ MOTOR CITY SOFTWARE │
│ ┌──────────────────────────────────────┐ │
│ │ JPDoor - Version 3.1 SE │ │
│ │ ┌──────────┐ │ │
│ │ │\ │ │ │
│ │ │ \ │ │ │
│ │ │ \ P │ │ │
│ │ │ \ A │ │ │
│ │ │ │ S │ │ │
│ │ │ │ C │ │ │
│ │ 5.5 │ │ A │ 6.0 │ │
│ │ │ o│ L │ │ │
│ │ │ │ │ │ │
│ │ \ │──────┘ │ │
│ │ \ │ │ │
│ └──────────────\ │─────────────────────┘ │
│ The Ultimate \│ Door Writing Unit. │
└────────────────────┴─────────────────────────┘
Don't be fooled! It's a dandy of a door interface.
Also, those who tested TAG_SHUT, Kevin Sawyer, Mike Thurlow (TAG ßeta site) and
Gary Green (TAG ßeta site).
Planned enhancements :
1) Inclusion of defineable sysop page call.
2) Capture of chat sessions
3) Finishing touches to error logging and exit codes for future support of
TAG (maybe). At present all local logons (in error or not) will allow a
successful entry to TAG which may not be desirable under certain circum-
stances.
4) Defineable chat times.
5) Call back verification (should prove interesting).
6) Rebooting of computer on failed local logon.
7) addition of some questionnaire goodies such as formatted phone number entry.
8) Sysop definition of menu commands.
9) Complete rewrite of code to eliminate use of JPDoor and reduce memory usage
dramatically. Current version (2.1) uses about 130k.
Enjoy the door!
Drew Smith (aka Faruk You)
Support :
Currently, only I support the program but that may change.
I can be reached via, TAG_DOORS, TAG, and TAG_BETA echos and via any of the
other TAG αlpha sites, or directly at:
(416) 549-2473 (The MutherBoard BBS, TAG αlpha site for Canada)
Via FIDONET 1:244/126, RBBSNET 8:990/300 - 301, TAGNET 26:1/111
Modem speed currently 14.4k but soon to be 9600 v.32